Subject: Updated multicast proposal (part 2)

From: Paul Brittain <[email-masked]>
Date: Thu, 21 Mar 96 05:05:00 GMT

7.DLSw Message Transports

With the introduction of DLSw Multicast Protocols,  SSP
messages are now sent over three distinct transport
mechanisms:  TCP/IP connections, UDP datagrams, and
Multicast Datagrams.

7.1  TCP/IP Connections

As is the case in RFC 1795, TCP/IP connections are
established between DLSws.  Unlike RFC 1795, however, TCP/IP
connections are only established to carry reliable circuit
data (i.e., LLC2 based circuits).
Accordingly, a TCP/IP connection is only established to a
given partner DLSw when the first circuit to that DLSw is
required.  In addition, the TCP/IP connection is brought
down an implementation defined amount of time after the last
circuit has terminated.

7.2  UDP Datagrams

Because the address resolution protocols have been moved out
of the TCP transport network, they are now sent via a
combination of multicast and UDP transport.    Generically
speaking, UDP based transport is utilized whenever an SSP
message must be sent to a unique DLSw.   This is typically
the case in address resolution responses.   There are,
however, some other cases where UDP is used to handle
directed UI NetBIOS frames such as STATUS_RESPONSE.
Further detail is provided  in the NetBIOS section of this
document.

7.3  Multicast Datagrams

Multicast datagrams are used to transport all broadcast
oriented UI traffic.  In the case of SNA, this is primarily
the CANUREACH_ex packets.  In the case of NetBIOS, multicast
datagrams are used to send
all broadcast UI frames.   A more detailed listing can be
found in the NetBIOS section of this document.

8.SNA Support

SNA protocols fall into two both Client/Server (SSCP/PU) and
Peer to Peer (T2.1 nodes and SSCP to SSCP) configurations.
But in both cases, all communication is LLC2 (or LLC2 like)
based.  (Note this paper does not attempt to address the
unique issues presented by SNA/HPR and its non-ERP data
links.)   Consequently, the generalized packet sequence of
interest is a test frame exchange followed by an XID
exchange.   The following paragraphs describe how multicast
protocol enhancements are used to establish SNA data links.

8.1  Address Resolution

When a DLSw receives an incoming test frame from an attached
data link, the assumption is that this is an exploratory
frame in preparation for an XID exchange and link
activation.  The DLSw must determine a correlation between
the destination LSAP (mac and sap pairing) and some other
DLSw in the transport network.   This paper generically
refers to this process as "address resolution".

DLSws use the following algorithm to correlate a given LSAP
to some partner DLSw in the transport network:

Note:  The pseudo code below is only an example of how a
DLSw may search its cache.  The actual search algorithm used
is implementation defined.

/* Begin */

Check the local cache
  If found
    Then do I=1 to retry_count
      Send a UDP based CANUREACH_ex is to the
corresponding DLSw
      If an ICANREACH_ex is received (within a timeout
window)
        then normal circuit setup is initiated
    End do

    Else do I=1 to retry_count
      Send a CANUREACH_ex to the appropriate multicast
address
      If an ICANREACH_ex is received (within a timeout
window)
             then normal circuit setup is initiated
    End do

/* Otherwise */
Circuit setup fails

/* End */

8.2  Explorer frames

ICR_ex and NR_ex messages may be sent over a TCP connection
to an up-level partner if such a connection already exists
in order that they take advantage of the guaranteed delivery
of TCP in order to avoid the need to send unicast retries
for these 'responses'.  However, it is an absolute
requirement that all V2 DLSw implementations support
multicast.

It is not permitted to send CUR_ex and ICR_ex over TCP pipes
that have been brought up solely for this purpose as this is
precisely the scalability issue we are trying to solve.
However, it may be useful to allow the sending of these
frames over the TCP pipe when, for example, validating a
cache entry.  In this case, unicast provides a lighter-
weight transport than a general multicast CUR_ex.

CUR_ex and ICR_ex frames must never be sent across a TCP
pipe and multicast at the same time as ths would defeat the
object of scalability.

8.3  Circuit Setup

Circuit setup is accomplished in the same manner as
described in RFC 1795.  More specifically, CANUREACH_cs,
ICANREACH_cs, REACH_ACK, XIDFRAME, etc. are all sent over
the TCP connection to the appropriate DLSw.   This, of
course, assumes the existence of a TCP connection between
the DLSws.   If the sending DLSw (sending a CANREACH_cs )
detects no active TCP connection to the partner DLSw, then a
TCP connection setup is initiated and the packet sent.  All
other circuit setup (and takedown) related sequences are now
passed over the TCP connection.

8.4  Multicast Reliability

It is important to note, that multicast services do not
provide a reliable means of delivery.  Existing RFC 1795
protocols guaranteed the delivery (failure notification) of
CANUREACH_ex and ICANREACH_ex messages.  Neither TCP
multicast or UDP will provide the same level of reliability.
It is therefore possible that these messages may be lost in
the network.

8.4.1  Retries

Test Frames are generally initiated by end stations every
few seconds.  Many existing DLSw implementations take
advantage of the reliable SSP TCP connections and filter out
test frame retries which a CANUREACH_ex is outstanding.
Given the unreliable nature of multicast and UDP transport
for these messages, this filtering is no longer advisable.
Although the RFC 1795 specification does not address this
issue directly, it would be prudent for DLSw implementations
to shorten the amount of time test frames are filtered.
Once this timer has expired, the next test frame should
result in a new CANUREACH_ex message.   The  filtering time
should be shortened to somewhere between the end station
retry timer and total link activation time (i.e.,
retry_timer < t < retry_timer x retry_count).  This way the
originating DLSw will filter some local test frame retries,
but periodically retry the CANUREACH_ex process from the
originating side.  It is advisable to maintain some way of
correlating retries to the original message.   This way late
responses to the original CANUREACH_ex can still be
correlated to the appropriate link activation attempt.
Note: There is no retry logic associated with ICANREACH_ex
messages.

The Retry timers and filter period are implementation
defined.  However it is recommended that the filter period
default should be one third of the total time that the DLSw
implementation will issue retries on the LAN (i.e. 1/3 *
(retry period * number of retries)).

Editors note:  The 1/3 value above was chosen by 'gut feel'
to be short enough to allow some retries but to filter out
any LAN retries that come in too frequently.  I would
welcome any other suggestions - especially if anyone has a
more scientfic basis for their suggestion.

9.NetBIOS

With the introduction of DLSw Multicast transport, all
NetBIOS UI frames are carried outside the TCP connections
between DLSws (e.g., via UDP and Multicast datagrams).   The
following table defines the various NetBIOS UI frames and
how they are transported between DLSws:

                                    Transport
    Message Event          Action         Mechanism
 ------------------------------------------------------------
 --------
ADD_GROUP_NAME_QUERY        SEND DATAFRAME
Multicast
ADD_NAME_QUERY           SEND NETBIOS_ANQ     Multicast
ADD_NAME_RESPONSE        Send NETBIOS_ANR     UDP1
NAME_IN_CONFLICT         SEND DATAFRAME       Multicast
STATUS_QUERY          SEND DATAFRAME       Multicast4
TERMINATE_TRACE (x'07')      SEND DATAFRAME
Multicast
TERMINATE_TRACE (X'13')      SEND DATAFRAME
Multicast
DATAGRAM                SEND DATAFRAME       Multicast
DATAGRAM_BROADCAST        SEND DATAFRAME       Multicast
NAME_QUERY              SEND NETBIOS_NQ_ex    Multicast4
NAME_RECOGNIZED          Send NETBIOS_NR_ex    UDP2
STATUS_RESPONSE          Send DATAFRAME       Multicast3

Note 1:
Upon receipt of an ADD_NAME_RESPONSE frame, a NETBIOS_ANR
SSP message is returned via UDP to the originator of the
NETBIOS_ANQ message.

Note 2:
Upon receipt of a NAME_RECOGNIZED frame, a NETBIOS_NR_ex SSP
message is returned via UDP to the originator of the
NETBIOS_NQ_ex frame.  Notice that although the
NAME_RECOGNIZE frame is sent as an ARE (token ring only)
frame, and the resultant NETBIOS_NR_ex is sent as a UDP
directed response to the DLSw originating the NETBIOS_NQ_ex.
This is because there is no value in sending NETBIOS_NR_ex
as a multicast packet in the transport network.  The use of
ARE transmission in the LAN environment is to accomplish
some form of load sharing in the source routed LAN
environment.  Since no analogous capability exists in the
(TCP) transport network, it is not necessary to emulate this
function there.   It is important to note, however, that
when converting a received NETBIOS_NR_ex to a
NAME_RECOGNIZED frame, the DLSw sends the NAME_RECOGNIZED
frame as an ARE frame.  This preserves the source route load
sharing in the LAN environments on either side of the DLSw
transport network.

All other multicast frames are sent into the transport
network using the appropriate multicast group address.

Note 3:
As a possible enhancement, STATUS_RESPONSE could be sent as
a UDP directed response, but only if the STATUS_QUERY is no
longer sent as a DATAFRAME. This is because the receiving
DLSw would need to process STATUS_QUERY in a special way.
In this scenario an incoming   STATUS_QUERY results in a new
NETBIOS_SQ SSP message which is multicast to all DLSws in
the group.   DLSws receiving this message remember the
originating DLSw's address and STATUS_QUERY correlator.  And
then upon receipt of a STATUS_RESPONSE, the DLSw responds
via UDP (using the remembered originating DLSw address) with
a new NETBIOS_SR message to the originating DLSw.

Note 4:

STATUS_QUERY and NAME_QUERY frames may be sent ARB or SRB on
the LAN.  However, these frames should always be multicast
on the WAN.  This ensures that when the location of a
NetBIOS resource is not known, the query reaches all up-
level DLSw implementations with minumum WAN traffic (though,
in a migration case, it may still be necessary for the
originating DLSw to send the frame over TCP to each down-
level DLSw partner separately).

In order to determine whether a frame is a STATUS_QUERY, all
up-level DLSw implementations will need to parse the
contents of frames that would normally be sent as DATAFRAME
SSP messages.

[EDITOR'S NOTE:  We cOuld introduce a new SSP frame type to
prevent this, but it s likely that all current
implementations are doing this anyway.  We probably also
want to use the multicast system for ADD_GROUP_NAME_QUERY
too.]
9.1  Address Resolution

Typical NetBIOS circuit setup using Multicast services is
essentially the same as specified in RFC 1795.   The only
significant difference is that NETBIOS_NQ_ex messages are
sent via Multicast IP and the NETBIOS_NR_ex is sent via UDP
to the DLSw originating the NETBIOS_NQ_ex.   Thus the
NetBIOS address resolution algorithm at an individual DLSw
would be as follows:

Note:  The pseudo code below is only an example of how a
DLSw may search its cache.  The actual search algorithm used
is implementation defined.

/* Begin */

Check the local cache
  If found
    Then do I=1 to retry_count
      Send a UDP based NETBIOS_NQ_ex is to the
corresponding DLSw
      If a NETBIOS_NR_ex is received (within a timeout
window)
        then normal circuit setup is initiated
    End do

    Else do I=1 to retry_count
      Send a NETBIOS_NQ_ex to the appropriate multicast
address
      If a NETBIOS_NR_ex is received (within a timeout
window)
             then normal circuit setup is initiated
    End do

/* Otherwise */
Circuit setup fails

/* End */

9.2  Circuit Setup

Following successful address resolution, a NetBIOS end
station typically sends a SABM/E frame to initiate a formal
LLC2 connection.   Receipt of this message results in
normal circuit setup as described in the SNA case.  That is
to say that the CANUREACH_cs messages etc are sent on a TCP
connection to the appropriate partner DLSw.  If no such TCP
connection exists, one is brought up.

9.3  Multicast Reliability and Retries

In the case of NetBIOS, many more packets are being sent via
multicast and UDP.  Therefore, the exposure to the
unreliability of these services is greater than that of SNA.
In addition, the retry interval for NetBIOS is considerably
shorter with the defaults being:  retry interval = 0.5
seconds and retry count = 6.   With this in mind, it is
recommended that DLSws endeavor to do the same thing as SNA
namely set the SSP retry interval somewhere between the
anticipated retry interval and total retry time (retry
interval * retry count).

10.  Sequencing

It is important to note that multicast services and UDP do
not provide guaranteed packet sequencing like TCP does for
RFC 1795.  In a steady state network, in order packet
delivery can be generally assumed.   But in the presence of
network outages and topology changes, packets may take
alternate routes to the destination and arrive out of
sequence with respect to their original transmission order.
For SNA address resolution this should not be a problem
given that their is no inherent significance to the order of
packets being transmitted via multicast and UDP.

In the case of NetBIOS, in order delivery is not guaranteed
in the normal case (e.g., LANs).  This is because LAN
broadcasting mechanisms suffer the same problems of packet
sequencing as do "wan" multicast mechanisms.   But one might
argue the greater likelihood of topology related changes in
the "wan" environment and thus a greater level concern.  The
vast majority of NetBIOS UI frames (being handled via UDP
and Multicast) have correlator values and do not rely upon
packet sequencing.

The only NetBIOS frames of special note would be: DATAGRAM,
DATAGRAM_BROADCAST, and STATUS_RESPONSE.  In the case of
DATAGRAM and DATAGRAM_BROADCAST it is generally assumed that
datagrams do not provide any guarantee of in order packet
delivery.  Thus applications utilizing this NetBIOS service
are assumed to have no dependency on in order packet
delivery.   STATUS_RESPONSE can actually be sent as a
sequence of STATUS_RESPONSE messages.  In cases where this
occurs, the STATUS_RESPONSE will be exposed to potential out
of sequence delivery.

11.  Migration

DLSws which implement these enhancements will indicate their
support for multicast protocols via the multicast
capabilities control vector in their capabilities exchange.
In this way, a DLSw can tell whether or not a specific
partner DLSw supports multicast.

11.1 Connecting to downlevel nodes

It is assumed that TCP connections to DLSws which do not
support multicast services are established by some means
outside the scope of this paper (i.e., non-multicast partner
addresses are configured by the customer).   TCP connections
must be established and maintained to down level nodes in
the exact same manner as RFC 1795 requires, establishes, and
maintains them.

11.2 Communicating with downlevel nodes

Because downlevel nodes will not receive SSP frames via
multicast or UDP transmission, these messages must be sent
over TCP connections to the downlevel nodes.   Therefore,
nodes which implement the multicast protocol enhancements
must keep track of which DLSw partners do not support
multicast extensions (as indicated in the capabilities
exchange).  When a given packet is sent out via multicast
services, it must also be sent over the TCP connection to
each downlevel node.   And although the multicast service
requires periodic retransmissions (for reliability reasons),
this is not the case with TCP connections to downlevel
nodes.  Therefore, SSP communications with downlevel nodes
should not be retried in accordance with the multicast/UDP
retry recommendations.  Furthermore, communications with
downlevel nodes should be in exact compliance with RFC 1795
protocols.

In the case of UDP based messages, UDP is only to be used
when destination DLSw is known to support multicast
services.  This knowledge can be obtained from previous TCP
connections/capabilities exchanges or inferred from a
previously received multicast or UDP message.   In practice,
this should not present a problem as UDP messages are only
sent in response to a multicast base request or for UI
frames when the local cache has information correlating the
destination LSAP with some specific DLSw.  In this case, if
the DLSw is downlevel, then there would be a TCP connection
to it and it would be known to be downlevel.  If it is not
downlevel and a TCP connection is in existence, then it's
level is known.  If it is not downlevel and there is not an
existing TCP connection, then it can be implied to be
uplevel (by lack of a TCP connection).   It may be prudent,
however, to cache the multicast capabilities of partner
DLSws.

Note:
When two uplevel DLSws have a established  TCP connection
multicast and UDP packets, as defined above, are NOT sent
over the TCP connection.  TCP connections between uplevel
DLSws are only used for reliable (LLC2) circuit setup,
circuit I-frame data, and circuit takedown.

12.  SSP Frame Formats

12.1 Multicast Capabilities Control Vector

This control vector is carried in the Capabilities Exchange
Request.  Like all control vectors in this SSP message, it
is an LT structure.  LT structures consist of a 1 byte
length field followed by a 1 byte type field.   The length
field includes itself as well as the type and data fields.

Byte Bit    Description
0   0-7    Length, in binary, of the multicast
capabilities control          vector (inclusive of this
byte)

1   0-7    Type:  x'8C'

2   0-7    Multicast Version Number:
            A binary numerical representation of the level
            of multicast services provided.  The protocols
            as identified in this document constitute
            version one.   Accordingly, x'01' is encoded in
            this field.  Any subsequent version must
            provide the services of all previous versions.

3-4        Reserved

5-n        Optional Control Vectors: parsed LT if present.
Currently, none defined.

The intended use of this CV for Multicast support is to
detect when the multicast CUR_ex flows will suffice between
partners.  If this CV is present in a cap-ex from a partner,
that partner is also up-level and therefore does not need to
receive CUR_ex messages over the TCP link  that exists
between them (and there must be one or else the cap-ex would
not have flowed) because it will receive the multicast
copies.

All DLSws implementing these enhancements must quietly
ignore any unrecognised optional CVs in bytes 5 onwards.  If
a Multicast capabilities CV is received containing
unrecognised optional CVs, the receiving DLSw must not
reject the capabilities exchange for this reason (though it
is permitted to reject the cap-ex with a negative response
if the vector is badly formatted or if there are other
errors in the cap-ex).

12.2 Multicast Packets

SSP frame formats are defined in RFC 1795.  Multicast
protocol enhancements do not change these formats in any
way.  But because the receiver of multicast packets may need
to respond to the originator, it is important to carry the
appropriate address of the multicast originator.   In
addition, the originator may have multiple IP addresses.
For example, a unique IP (non-multicast) address, a peer to
peer multicast address, and a server multicast address.
Consequently, SSP frames are encapsulated in a special
multicast frame header which carries the originators unique
IP address and any applicable multicast address for
responses.

Byte Bit    Description
0-1        Length (inclusive), in binary, of the multicast
header           (the frame length can be obtained from
IP)

1   0-7    Multicast Version Number:
            A binary value corresponding to the multicast
            version number indicated in the Multicast
            Capabilities Control Vector of the sender.

2-5        Originating IP Address:
            IP (non-multicast) address of the sending DLSw.
            Always present (note: we probably should make
            this generic... but I didn't have the time to
            investigate proper frame formats)

6-9        Originating Multicast Address:
            Multicast address of the sending DLSw.  The
            multicast address used should be the one
            associated with the group in question.
            Determining group context is outside the scope
            of this document, but the section entitled
            "Multicast Groups" should provide appropriate
            context.  One item of note is that when the
            role within a group is either client or server,
            messages should be sent to the opposite role
            and the originating multicast address should
            reflect the role within the group.

10-n       Encapsulated SSP Frame

12.3 UDP Packets

As mentioned above, SSP frame formats are defined in RFC
1795.  Multicast protocol enhancements do not change these
formats in any way.  But because the receiver of UDP packets
may need to respond to the originator, it is important to
carry the appropriate address of the UDP packet originator.
Consequently, UDP SSP frames are encapsulated in a special
UDP frame header which carries the originators unique IP
address.

Byte Bit    Description
0-1        Length (inclusive), in binary, of the header
(the total            packet length may be obtained from
UDP)

1   0-7    Multicast Version Number:
            A binary value corresponding to the multicast
            version number indicated in the Multicast
            Capabilities Control Vector of the sender.

2-5        Originating IP Address:
            IP (non-multicast) address of the sending DLSw.
            Always present (note: we probably should make
            this generic... but I didn't have the time to
            investigate proper frame formats)

6-n        Encapsulated SSP Frame